"Nathan Kopp" wrote:
> pigment_pattern{
>   average
>   color_map{
>     [<alt_weight> gradient <alt_vect>
>        color_map{[<lo_alt> rgb 0][<hi_alt> rgb 1]]
>     [<slope_weight> slope <slope_vect>
>        color_map{[<lo_slope> rgb 0][<hi_slope> rgb 1]]
>   }
> }

This would work very well except that there's one big problem.
A vital feature of lo_alt and hi_alt is that they are not restricted to the
0 to 1 range. If you have a mountain that goes from -5*y to 5*y you set
lo_alt and hi_alt to -5 and 5 respectively. This is not possible with your
method. You would have to scale and translate the gradient instead and even
that wouldn't quite give the same pattern since the gradient pattern
increases in value in both the positive and negative direction. I guess the
gradient pattern uses some abs functions. Also, it would only work with
alt_vect being x, y, or z. Have you ever tried using gradient with other
vectors? It gives undesired results again because of the abs functions.

I think version 2 and 3 should be preserved. I won't go into details with
version 2, but concentrate on version 3 which seems to be the one many find
confusing. I personally think version 3 is highly useful. Actually, after
having learned it I'd suggest that everybody *always* use version 3 instead
of version 2, since it makes it much easier to get controllable results.

I do think the slope pattern should be changed though.

Most important suggestion:

Currently slope pattern values repeats with the mod function when values are
outside the 0 to 1 range. This is doubly useful for anything and it often
makes it difficult or just unnecessary tiresome to get desired results. I
suggest that the values are clipped. The clipping should occur *before* the
weighted addition of slope and altitude.
The slope value should be clipped so values below lo_slope becomes 0 and
values above hi_slope becomes 1. (lo_slope and hi_slope defaults to 0 and 1
respectively when not specified.)
The altitude value should be clipped so values below lo_alt becomes 0 and
values above hi_alt becomes 1.
The weighted addition happens *after* those clippings. That is more
intuitive to the user than if the final value is clipped.

Another suggestion is to change syntax from

<slope>, <altitude>, <lo_slope,hi_slope>, <lo_alt,hi_alt>

to

<slope>, <lo_slope,hi_slope>, <altitude>, <lo_alt,hi_alt>

This makes it possible to use lo_slope and hi_slope also when altitude is
not used at all.
Sure, it also means that you cannot use altitude without using the lo_ and
hi_ vectors too, but as I said it should only make it easier to understand
for the user.

I personally think the lo_ and hi_ vectors are easier to understand when you
think of <slope> and <lo_slope,hi_slope> as one unity and <altitude> and
<lo_alt,hi_alt> as another unity. First understand the two individual
unities and then care about the interaction (weighted addition) afterwards.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message